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A method of electronic payment for data transferred across , 
a computer network from a server [(26)] to a client [(20)] by 
means of at least one router [(22, 24)] which forwards data.' 
An electronic data request is sent from the client to the 
server via one or more routers. The server [(26)] then sends 
electronic data [(8)] to the client [(20)] via one or more 
routers in response to said electronic data request. The 
electronic data is sent via a packet transfer protocol, in 
which each packet of data [(10)] has associated with it a data 
field [(5)] containing a [value] value, which represents the 
commercial value of the requested data [(8)]. Each router 
[(22, 24)] receives an incoming data packet [(10)], reads the 
value in the data field [(5)] associated with the incoming data 
packet, calculates a new value based on the read value and 
the cost of forwarding the data packet, and forwards the data 
packet [(10)] with the new value in the associated data field 
[(5)]. Each router can check whether the value in the data 
field [(5)] associated with the incoming data packet falls 
within predefined ["parameters".] parameters and rejects the 
packet if the value falls outside the predefined parameters, 
for example if the value of the data is too high. Each router 
stores the accumulated value of received and forwarded 
data, so that payments may be made to the operator of the 
router. 
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COMPUTER NETWORK PAYMENT SYSTEM 

TECHNICAL FIELD 

[0001] The invention relates to a system and method for 
transferring payments corresponding to the supply of infor- 
mation over a computer network. In particular the invention 
relates lo a system and method for transmitting payment 
information between servers and clients by means of a 
hardware infrastructure of linked routers and by means of a 
specially adapted protocol. The protocol used by the system 
and method of the invention is referred to herein as "Packet 
Tariff Protocol*' or "PTP". It is to be understood that the term 
PTP when used in the following description should be taken 
to mean a protocol adapted for use with systems which 
transfer data in packets between servers and clients, the 
protocol enabling the transmittal of payment information 
between the servers and clients. 

[0002] It is also be to understood that the term "packet" 
when used in the following description should be taken to be 
a generic term, meaning any discrete package or block of 
data that is described by any particular protocol, as appro- 
priate to any particular communication layer. For the pur- 
poses of the following description the term "packet" should 
therefore include message, segment, datagram, frame and 
any other term which by definition or common usage is 
accepted as meaning a discrete package or block of data in 
the context of a specific protocol, as appropriate to any 
particular communication layer. 

BACKGROUND OF THE INVENTION 

[0003] Access to the Internet is freely available every- 
where and the advent of e -commerce, or electronic trading, 
is set to revolutionize the way that business is done. How- 
ever there remains a requirement for effective trading of 
information itself. As the infrastructure and available band- 
width expand to appropriate levels, the world will become a 
single, on-line, global, multimedia library. All public domain 
information will be available to anyone with a network 
connection, via a simple, easy to use interface, analogous to 
today's Web browser application. In addition, suitable tools 
will be developed to manage the information and tailor all 
that is available to suit the particular needs of each indi- 
vidual. There are two major consequences of this, as fol- 
lows. 

[0004] Firstly, holding information locally will become 
redundant. This means that books, CDs, prerecorded video- 
tapes and so on will eventually not be required. When 
information is sufficiently cheap and reaches the necessary 
levels of specificity and availability, there will be no point in 
individuals holding local copies of the information, in the 
form of books, CDs, tapes etc., that will quickly go out of 
date. They will simply access the latest, updated information 
from its original source or retrieve other data (noting that 
any digital multimedia information is fundamentally just 
data) from on-line archives. 

[0005] Secondly, broadcast media will also become redun- 
dant. Radio stations, TV channels, newspapers and journals 
will no longer serve any purpose. Once again, highly sophis- 
ticated information management tools will retrieve informa- 
tion from the massive range of disparate original sources 
that will come into existence, with the output collated, 



rationalized and customized to match the particular require- 
ments of each networked individual. 

[0006] These changes lie in the future, but are inevitable, 
and are likely to result in commercial upheaval and colossal ; 
social changes. At present, however, there remains a press- 
ing need for a consistent and appropriate system or method' 
to permit the implementation of this trade in information. 
The system must conform to, and operate under, the condi- 
tions that exist within free-market commercial and national 
economies. It is the development of a proposed solution to 
this [problem] problem, which is addressed by the present 
invention. 

SUMMARY OF THE INVENTION 

[0007] The PTP or "Packet Tariff Protocol" is an element 
within an effective system for digital networks at packet 
level. The protocol is envisaged as, but not limited to, an 
evolution of the existing TCP/IP (Transmission Control 
Protocol/Internet Protocol) standard that forms the core of 
the Internet as it presently exists. However PTP is not 
limited to TCP/IP applications, but can be used in any 
environment where there is transfer of data in distinct pieces 
or packets, for example WAP (Wireless Application Proto- 
col), UMTS (Universal Mobile Telecommunications Sys- 
tem), GPRS (General Packet Radio Service) or others. 

[0008] According to a first aspect of the present invention 
there is provided a method of electronic payment for data 
transferred across a computer network containing at least 
one client, at least one server and at least one router which 
forwards data, the method comprising the steps of: 

[0009] sending an electronic data request from a 
client to a server via one or more routers; and 

[0010] sending electronic data from [said] the server 
to [said] the client via one or more routers in 
response to [said] the electronic data request, [said] 
the electronic data having associated with it a data 
field containing a value which represents the com- 
mercial value of the data contained within the elec- 
tronic data. 

[0011] Preferably the electronic data is transmitted in the 
form of packets. Preferably each of [said] the one or more 
routers receives an incoming data packet, reads the value in 
the data field associated with the incoming data packet, 
calculates a new value based on the read value and the cost 
of forwarding the data packet, and forwards the data packet 
with the new value in the associated data field. 

[0012] Preferably each of [said] the one or more routers 
checks whether the value in the data field associated with the 
incoming data packet falls within predefined parameters and 
rejects the packet if the value falls outside the predefined 
parameters. The parameters may depend on the source of the 
data packet or the originator of the data request. 

[0013] The electronic data request may also have associ- 
ated with it a data field containing a [value] value which 
represents the commercial value of the data contained within 
the electronic data request. 

[0014] Preferably total accumulated values for transac- 
tions between routers or between routers and servers/clients 
are recorded. These total values may be used as the basis for 
payments between the operators and/or users of the routers, 
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servers or clients. Periodic clearance payments may be made 
between the operators and/or users of the routers, servers or 
clients, the clearance payments corresponding to the total 
accumulated values. 

[0015] According to a second aspect of the present inven- 
tion there is provided a system of electronic payment for 
data based on a hardware infrastructure of linked routers, 
data providers and data users, comprising: 

[0016] at least one client; 

[0017] at least one server for providing electronic 
data in the form of data packets in response to a 
request from a client and having its operation gov- 
erned by a server protocol which causes each data 
packet sent by the server to have associated with it a 
data field representing the value of the data contained 
within the packet; 

[0018] al least one router linked by a hardware infra- 
structure to [said] the server and [said] the client and 
having its operation governed by a routing table and 
a router protocol; and 

[0019] whereby the router protocol causes each 
router to add commercial value to the packet by 
forwarding it in accordance with the routing table 
and to update the value contained in the data field 
within the packet to reflect this added commercial 
value. 

[0020] Preferably the router protocol also includes proce- 
dures for rejecting individual packets in accordance with 
pre-defined parameters related to the value of each packet on 
receipt. 

[0021] According to a third aspect of the invention there is 
provided a method of electronic payment for data transferred 
across a computer network containing at least one client, at 
least one server and at least one part of the network which 
forwards data, the method comprising the steps of: 

[0022] sending an electronic data request from a 
client to a server via the part of the network; and 

[0023] sending electronic data from [said] the server 
to [said] the client via the part of the network in 
response to [said] the electronic data request, [said] 
the electronic data having associated with it a data 
field containing a value which represents the com- 
mercial value of the data contained within the elec- 
tronic data. 

[0024] Preferably the electronic data is transmitted in the 
form of packets. Preferably the part of the network has an 
associated data processor which reads the value in the data 
field associated with an incoming data packet received by 
the part of the network, calculates a new value based on the 
read value and the cost of forwarding the data packet, and 
forwards the data packet with the new value in the associated 
data field. 

[0025] The data processor may check whether the value in 
the data field associated with the incoming data packet falls 
within predefined parameters and rejects the packet if the 
value falls outside the predefined parameters. 

[0026] According to a fourth aspect of the invention there 
is provided a method of electronic payment for requested 



data transferred across a computer network containing at 
least one client, at least one server and at least one router 
which forwards data, in which the requested data is sent 
from [said] the server to [said] the client in the form of a 
packet, 

[0027] wherein [said] the packet comprises a packet 
header and packet data, 

[0028] the packet data containing the requested data, 
and the packet header containing one or more 
address fields containing address information relat- 
ing to the client and/or server and a data field 
containing a value which represents the commercial 
value of the requested data contained within the 
packet data. 

[0029] Preferably the data is sent via the router which 
reads the value in the data field of the incoming data packet 
received by the router, calculates a new value based on the 
read value and the cost of forwarding the data packet, writes 
the new value to the data field, and forwards the data packet 
with the new value in the data field. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0030] The invention will now be described, by way of 
example only, with reference to the accompanying figures, 
where: 

[0031] FIG. 1 is a schematic representation of a typical 
generic form of a digital data packet under the system of the 
invention; 

[0032] FIG. 2 is a schematic representation of a fragment 
of a network; and 

[0033] FIG. 3 is a flow chart showing the operation of a 
network router under the system according to the invention. 

DETAILED DESCRIPTION OF THE 
INVENTION 

[0034] The invention can best be understood by consid- 
ering the metaphor of the supply chain with associated 
added value at each stage. In other words, at each step in the 
process to supply the information, value is added over and 
above the intrinsic value of the information. Therefore, an 
additional cost is associated with the information at each 
stage, until it reaches its ultimate destination. In practice, 
this is achieved by the incorporation of a "value" field into 
each data packet, allied with network protocol extensions to 
implement and utilize this field in the packet. This is applied 
in a way that ultimately results in the cost of providing the 
intrinsic information and the cost of providing the transport 
service being enumerated and accrued in the value field. 
These costs are thus accounted for within the same system 
that actually provides the data transport service, so that the 
supply chain and the value chain are both incorporated into 
the network protocols. 

[0035] The value field may be augmented with a "priority" 
field, along the lines that have already been proposed by 
other bodies as part of existing technical specifications. 
Within this framework though, the priority field can addi- 
tionally be used as part of the commercial system if required, 
so that different services can incur different costs although 
they may share the same hardware and network infrastruc- 
ture. In some prior art developments, the "priority" field of 



US 2002/0083186 Al 



3 



Jun. 27, 2002 



a data packet has evolved to serve a more advanced purpose, 
and the field contains a code that indicates how data should 
be handled, according to its characteristics. For example, 
transmission of data that is part of a video stream might not 
be re-tried if it fails first time, since a degraded video output 
is considered to be more useful to the ultimate end-user than 
a pause to wait for all the information to achieve perfect 
reproduction. In contrast, a file transfer can usually wait for 
the availability of network capacity, but must ultimately be 
one hundred percent complete, accurate and checked if it is 
to be of practical use. 

[0036] In the system according to the invention, data is 
transferred between servers and clients in packets. FIG. 1 
shows the typical generic form of a digital data packet under 
the implementation of PTP. 

[0037] The packet 10 is simply data in a mutually under- 
stood format. In the example of FIG. 1, it is divided into 
three sections 1, 2, and 3. Each section may be further 
divided into multiple fields, as described below. The packet 
header 1 contains general fields 4 for addressing information 
or other information and also contains a value field 5. The 
number of general fields 4 depends on the protocol used, and 
it is to be understood that the number of general fields 4 and 
the position of the value field 5 within the packet header 1 
may vary. The packet data 2 contains the data 8 and follows 
the packet header 1. The packet tail 3 follows the packet data 
2 and is optional, but would typically contain a field 6 
containing the checksum for the packet, or similar error 
detection information, and may contain other general fields 
7. Again it is to be understood that the number of general 
fields 7 and the position of the checksum field 6 within the 
packet tail 3 may vary. It is to be understood that the value 
field may be in any position within the packet, for example 
within the pay load or packet data 2, or within the packet tail 
3. 

[0038] Each data packet 10 includes a value field 5, which 
contains information about the intrinsic value of the data 8 
contained within the packet, and which accumulates the 
charges made for each step in the provision of the service for 
supplying that data packet to its ultimate recipient. As an 
example, this aggregated overall worth may be measured in 
Network Credit Units (NCU's). 

[0039] For the purpose of applying tariffs, the network 
system is considered to consist of "servers", "routers" and 
"clients" although in practice a single machine or even a 
single software application may [fulfil] fulfill more than one 
of these functions at different times. For example, a router 
can be considered to be acting as a client to many servers and 
as a server to many clients, as defined by the routing tables 
to which it adheres at any particular moment in time. 

[0040] FIG. 2 is a diagram showing a network fragment. 
Under the system of the invention it may operate in the 
following manner. The web client 20 operated by the ulti- 
mate end user requests information in the form of a message 
that passes through router (N) 22 at the internet service 
provider (ISP) connection and accrues added value as a 
result of the action of the transport service. The message 
subsequently passes through a number of intermediate rout- 
ers (not shown) and finally through router (A) 24 and 
accrues more added value for the extra transport service. The 
intermediate routers and routers (A) and (N) form the 
network infrastructure carrying the data. The message then 



arrives at the web server 26, which responds by initiating a 
data stream. The web server 26 is operated by a content 
provider. The packets of this data stream typically have 
intrinsic value, associated with the information that they 
contain, the information being provided or sold by the 
content provider. The appropriate component of this intrin- 
sic value is recorded in each packet. The packets then pass 
back via router (A) 24 and have the associated value of the 
transport service added to them. Similarly, router (N) 22 
passes the data stream and adds further value to the packets 
for the service provided. The information finally arrives at 
the web client 20, as required. 

[0041] For each machine on the network, the net values of 
packets received and transmitted via each hardware connec- 
tion can then be calculated. These values are reconciled by 
the owners of all the machines involved, as the basis for 
assessing the economic value of the services provided and 
calculating the commensurate hard currency exchanges 
required. This process is described in more detail below. 

[0042] In accordance with the PTP idea, the web client 20, 
or any software application functioning as a client, main- 
tains the right to reject individual packets if they are deemed 
"too expensive" by some criteria, without assuming their 
associated notional cost. Additional control is maintained by 
monitoring the value of incoming packets in real time, 
typically by summing the total value arriving in the last 
second and/or minute and/or hour and/or other time interval, 
as required. This might, for example, be depicted by a meter 
representation or bar indicator on a network terminal screen. 
Over a short time period, of the order of a few seconds or so, 
it might be acceptable to have a large amount of data arriving 
with a large value at a high rate of value accrual, for example 
when downloading a software application. However over a 
longer time period, of the order of an hour or so, a high rate 
of value accrual might be unacceptable while it might be 
acceptable to have a continuous stream of data arriving with 
a smaller value, for example when downloading a movie or 
video in real time. A meter representation could also apply 
to an Internet telephone, and the system could show the cost 
of a call as it takes place, rather than the owner subscribing 
to the service on a predetermined tariff scheme. This does 
not preclude a service provider agreeing to absorb the 
fluctuations in cost and passing on packets at agreed rates if 
such a service is desired by clients on the network. This 
might be appropriate, for example, if a client actually 
desired predetermined costs for use of the system, e.g., for 
budgeting purposes. 

[0043] The invention is now described in more detail. For 
the purposes of the description herein, a packet originates 
from a server that acts as a "content provider", i.e., it is the 
source of the data or information contained within the packet 
that is to be transferred. This piece of information and the 
service of providing it both have some inherent worth and 
this worth can be enumerated and written in the value field 
of the packet. This is the first element of the system of the 
present invention, in that content providers can attach a 
value to the information that they provide and, further, they 
can assert the claim to that value along the same delivery 
channel as that by which the information itself is supplied. 
On receipt of the packet, the client (or router acting as a 
client) can accept the packet or reject it. The control [system] 
system, which makes the decision and determines the out- 
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come of this choice is described later. It is of importance, 
because information cannot meaningfully be returned once 
received. 

[0044] Assuming that a router receives and accepts a 
packet, it then acts in its role as a server and forwards it in 
accordance with the routing tables it currently holds. It 
should be noted that this always entails sending the packet 
down a physical data connection of some sort. The network 
is defined by the routing tables, but always has a physical 
existence as data conduits between machines. In the system 
of the invention, the routing machine defines the worth 
associated with the action of passing a packet from one 
machine to the next. It might be a fixed rate, or it might be 
dependent on the priority of the packet or on some other 
parameters (e.g., network loading, time of day, physical 
distance between machines, available bandwidth, ownership 
of network infrastructure, etc.). The important point is that 
this evaluation can be resolved by the router (probably as 
part of its routing software) as it passes the packet and that 
the outcome of this calculation is added to the value field of 
the packet in transition (i.e., before it is forwarded). This is 
the second element of the system of the present invention, in 
that network infrastructure providers can attach a value to 
the service of transporting information and, further, they can 
assert the claim to that value along the same delivery 
channel as that by which the information itself is supplied. 
It is also necessary for each machine to accumulate the total 
number of NCU's it receives from each physical connection 
and the total number of NCU's it dispatches to each physical 
connection, excluding those attributed to packets that are 
subsequently rejected. It should also be noted that physical 
connections for the receipt of packets are considered to be 
distinct from physical connections for the dispatch of pack- 
ets, even though they might be manifested in the same piece 
of cabling. 

[0045] Under these conditions, the number of NCU's 
transmitted from the machine at one end of a physical 
connection should agree with the number of NCU's 
accepted by the machine at the other end. These machines 
may be owned by different organizations but, on the basis 
that they agreed to make the trades, they should be reason- 
ably expected to have mutual interest in ensuring accuracy 
in accounting. A commercial analogy for this would be a 
deal done on an "open outcry" trading floor, in which two 
parties agree a deal by signals and each makes a record of 
it independently. The independent records are reconciled at 
a later stage but, since both parties agreed the initial deal, 
both are assumed to have an interest in making sure that it 
is recorded accurately. The analogy goes further, since any 
party that establishes a reputation for not recording deals 
accurately will simply find it impossible to establish or 
maintain any profitable trades. 

[0046] Within this protocol, any recipient reserves the 
right to reject any packet. This rejection includes refusal to 
accept the debt associated with receipt of the packet. The 
most probable reason for this is that the packet is deemed by 
some criteria to be "too expensive". This act of rejection is 
an important part of the protocol and therefore warrants 
detailed discussion. As discussed above, once data is 
received it cannot be meaningfully returned, since it is not 
a physical object. On first inspection, then, it seems that 
there would be a propensity to defraud suppliers by rejecting 
packets (and therefore the liability to pay for them) whilst 
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still forwarding the data and charging for it. However, the 
post-receipt rejection process is vital to remove completely 
the possibility that single "rogue" packets of massive value 
are foisted on unsuspecting recipients. The reason that an 
immediate breakdown of the system according to the inven- ' 
tion does not follow is because successful trading requires, 
streams of many packets of modest value to be passed 
through the network. In the proposed scenario, the "catch 
'em once" price-value combination is excluded by this 
ability to refuse to pay for excessively costly packets. This 
means that a sustainable and profitable trade will only occur 
with the transmission of an ongoing packet stream. 

[0047] This "reject" aspect of the system according to the 
invention may best be understood by considering a "sale or 
return" analogy. A producer (content provider) creates a 
product (data/information) and delivers it to a reseller 
(router) at some cost (the value in NCU's). The reseller 
(router) either accepts it, on the basis that it can be sold on 
(forwarded to another router or an end client) al a marked up 
price (an addition to the value in NCU's) or, alternatively, 
rejects it. The producer (content provider) monitors the 
rejections of the reseller (router) and decides on the basis of 
this information whether or not to continue trading and, if so, 
what price structure to apply. Hence, the choice of accep- 
tance or rejection of a packet is effectively a "sale or return" 
of the data, since keeping occasional packets without paying 
for them is of little economic value. In practice, it will 
rapidly become the case that meaningful trade in packet 
streams allied to competitive pricing is the only way to 
maintain profitable transactions. 

[0048] Termination criteria are based upon single packet 
costs and the cost accumulations of packets over selected 
time intervals. Hence termination requests are issued if any 
single packet exceeds the NCU threshold or if the limits for 
NCU's per second, minute, hour, day and/or other time 
interval are exceeded. The cut-off levels are best kept 
confidential to avoid prices being bumped up to the maxi- 
mum that would be accepted, although such information 
could be shared with trusted counterparts in an attempt to 
reject packets deemed too costly at an earlier stage. Note that 
single-packet rejection is the only rejection where packets 
are not paid for, other termination is simply a request to 
cease supplying data. Data received before supply termi- 
nates are still paid for, subject to single packet criteria. 

[0049] Conversely, the value attributed to data by content 
providers could be freely advertised. This would make 
competition between content providers more effective and 
would also highlight expensive transport routes, since the 
value of the packet received would have had risen unac- 
ceptably when compared to the initial value advertised by 
the content provider. Furthermore, data network routing 
should become an extremely efficient market because data 
transmission networks can be reconfigured so easily and 
pricing structures changed so readily. This should result in 
perfect competition, evolving to satisfy the laws of supply 
and demand in a free market. 

[0050] The final element of the system according to the 
invention is achieved by converting the residual difference 
in NCU's exchanged between a pair of machines over some 
physical connection into a payment in mutually acceptable 
hard currency. This can always be achieved bilaterally, but 
could also be administered by some kind of clearing house 
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with responsibility for a defined physical region of the 
network. There is a potential problem here, unless the 
exchange value of an NCU is pegged to some hard currency. 
Otherwise, it will float erratically as the number of NCU's 
per network transaction can vary inversely with the 
exchange rate to hard currency, without changing the actual 
monetary worth of the network transaction. The problem 
might however eventually resolve itself if the NCU becomes 
a stable, global currency in its own right. 

[0051] To complete a transaction using this system, an 
ultimate client could first issue a request for some informa- 
tion. For the purpose of this example only, it will be assumed 
that this request is contained in a single packet. The intrinsic 
value of this packet would probably be zero but, in all cases, 
could not exceed a predetermined maximum accepted by the 
router (which may well be the machine' of a network service 
provider, acting at this point as a client). Further, since this 
machine is probably not owned by the owner of the ultimate 
client machine, there would be no tariff added to the value 
of the packet. The router, now acting as a server, adds a tariff 
to the packet and passes it to the next router. This process is 
repeated across the network until the packet reaches the 
machine of the content provider that, somewhat confusingly, 
is at this point acting as a client. Hence, the content provider 
receives a request for information but becomes liable for the 
accrued value of the packet. This value will be relatively 
small, since it is only one packet (or, more generally in 
practice, a relatively small number of packets) and it has 
little or no intrinsic value in its information content. It can 
be thought of as analogous to the cost associated with a 
free-phone telephone number that businesses commonly use 
to attract enquiries from customers. 

[0052] The machine of the content provider now acts in its 
primary role as a server, and starts to send packets addressed 
to the machine of the ultimate client (i.e., the machine from 
which the original request for data originated). Since the 
packets have content that is deemed to have some worth, 
these packets now have a significant value associated with 
them even as they are dispatched from the server machine. 
As they traverse the network, they will accrue further value 
until they reach the ultimate client machine. Routers within 
the network will have added value to packets passing both 
ways, so that owners of these machines will be in residual 
credit after paying for the packets received and will there- 
fore be able to reclaim hard currency converted from NCU's 
to finance their activities. The content providers will have 
some liabilities for the receipt of the packets requesting data 
but will have a large residual credit for supplying the 
information. The ultimate client will contribute the majority 
of the payments due, which cover the cost of the information 
they receive and the cost of the process of transporting it to 
them. 

[0053] The way in which a network router might imple- 
ment the PTP, in addition to its existing transport protocol, 
for the purposes of transferring data packets and accumu- 
lating the associated tariffs, is illustrated in the flow chart of 
FIG. 3. The branches in the flow chart show possible 
contingencies at various stages, if the required conditions 
are not satisfied. 

[0054] The router receives 30 a data packet and checks 32 
whether the packet is acceptable under the existing transport 
protocol. The router also checks 32 whether the routing 



tables with which it is provided can resolve the address to 
yield the hardware connection along which the packet is to 
be dispatched. If the packet is acceptable and the address can 
be resolved the router proceeds to step 36. If the packet is not 
acceptable or the address cannot be resolved the router 
rejects 34 the packet. 

[0055] The router then checks 36 that the value of the 
packet as determined from the value field 5 is below the 
value limit acceptable from the incoming hardware connec- 
tion. If the value of the packet is not below the value limit 
the router rejects 38 the packet under the PTP rules. If the 
value of the packet is below the value limit the router 
proceeds to the next step, in which the recorded total value 
received from this hardware connection is incremented 40 
by the value of the packet. The recorded total value received 
is stored by the router. 

[0056] The router then calculates 42 the value to be added 
for the service of transmitting this packet along the particu- 
lar hardware connection designated by the routing tables. 
Ill Is might depend upon the infrastructure of the hardware 
connection, the prevailing network loading, the time of day 
and many other factors. The router then increments 44 the 
packet's value field [5], which is the packet's internal record 
of its own value by this calculated value. 

[0057] The router then transmits 46 the packet along the 
hardware connection along which the packet is to be dis- 
patched. Following transmittal the router checks 48 that the 
recipient machine has acknowledged successful transfer of 
the packet (assuming the transfer protocol supports this). If 
the transfer is not successful, then this is handled under the 
existing transport protocol 50. If the transfer is successful 
the router increments 52 the recorded total value transmitted 
to this hardware connection by the value of the packet. The 
recorded total value transmitted is stored by the router. 

[0058] For each router or hardware connection, the total 
value transmitted minus the total value received (e.g., in 
Network Credit Units) is the net profit (or loss) that must be 
reconciled with the owner of the machine at the other end of 
that hardware connection. This is used to determine the 
economic value of the accumulated transactions and forms 
the basis of the hard currency exchanges necessary to 
finance the activities and the provision of the infrastructure. 

[0059] Physical network connections can be created and 
re-arranged relatively easily and network service providers 
can normally be changed at will. It is therefore anticipated 
that the kind of business system envisaged by the present 
invention will lead to a very e Ancient market constituted of 
very many providers of connections and routing bandwidth 
who serve, collectively, a very large number of content 
providers and information consumers. For example, if the 
financial arrangements were controlled in this manner, it 
might reasonably be envisaged that the infrastructure would 
evolve to support video on demand. This would be based 
upon an enormous supply of material, effectively a distrib- 
uted archive of all the material ever produced. It would 
satisfy the market by the laws of supply and demand. 

[0060] One of the major problems associated with any 
data distribution, and particularly digital data, is that of 
unauthorized redistribution. Matters of privacy and security 
are also general problems in the context of the Internet. For 
the purposes of the description of the invention, it is nec- 
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essary only to consider whether the use of PTP implies any 
changes as compared to the situation at present. The system 
of the invention does not require transfer of data in ways 
other than those presently possible, and the proposed pro- 
tocol of the invention would not inhibit any of the security 
or encryption methods used to prevent such [unauthorised] 
unauthorized redistribution. In fact, security and encryption 
would be expected to take place at the level of the data 
within the packet stream, rather than acting at the packet 
level itself. 

[0061] One important feature of the system of the inven- 
tion is that it allows consumers to choose exactly what they 
require without having to pay for unwanted accompanying 
material. For example, they can select one track without 
having to pay for a complete music CD, or they can decide 
not to view the remainder of a film if they dislike the opening 
portion. Also, the purchase price should be subject to very 
keen competition. These facts in themselves mean that there 
is less temptation to acquire material from illegal sources. 
Any legal deterrents become more effective if individuals 
can buy selectively only what they actually require, and at 
a fair price. 

[0062] In addition, as individuals are presented with, and 
begin to utilize, the much greater choice of available infor- 
mation, their interests will rapidly diversify and their 
requirements will diverge. This will have the effect of 
making it more difficult to cache data as it passes through the 
network and resell it multiple times. If content becomes 
sufficiently cheap, it will not be worth the investment in 
hardware to cache it. There will be less demand for any 
particular content, so that the logistics of illegal storage for 
reselling become more expensive and therefore less attrac- 
tive. This is not to say that a legal business of caching and 
reselling popular information could not build up, still within 
this framework. This could, for example, be how what are 
now broadcast services continue to make money. Network 
capacity will need a large step-change before commonly 
required content can be served to all clients from a single 
source, a matter which is presently addressed by the use of 
network caches, proxy servers and mirror sites on the Web. 
Such issues are tied in with copyright and ownership of 
content. For example, it is not generally possible for an 
end -user to tell whether content comes from its original 
provider or from some legitimate or illegitimate cache. Once 
again, the implementation of the system of the invention 
would not impact upon these matters of copyright and 
ownership of content. 

[0063] The system of the invention as described above can 
also function with the concept of the network computer, 
which for example means that a user might have the option 
of purchasing the use of a software application for some 
period rather than actually buying the application outright. 
Once again, they receive (and pay for) only what they 
actually require, and always get the most up to date version 
so that rapid obsolescence is not a concern. 

[0064] One other important feature of the PTP concept is 
that it can be interfaced with a conventional network, 
operating under a different business model, provided charg- 
ing rates and so forth are agreed for the interfaces. This 
means that network fragments can be created or converted to 
conform to the PTP model as and when suits the infrastruc- 
ture owner, so that gradual conversion is possible and a 
massive "roll-out" program is unnecessary. 
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[0065] It is possible that, for effective operation, the 
system of the invention will require international financing 
deals and clearing arrangements, as well as software con- 
trolled real-time network configuration changes and real- , 
time pricing structure changes. However, the system of the 
invention offers two significant advantages, as follows: 
Firstly, the ultimate client always has transparent data on 
what the service being received is actually costing, over any 
desired time interval. This is regardless of the choice of 
information source, network service or demand driven cost- 
ing changes. Secondly, PTP represent a good approximation 
to a perfectly competitive and efficient market, and one in 
which the costs and revenues are intimately related at all 
stages to the actual activities from which they result. These 
features should be expected to encourage serious investment 
into infrastructure development. 

[0066] Particular details of a method of implementing PTP 
in a TCP/IP environment will now be described. In particu- 
lar, for the value quantity to be directly accessible for 
processing by the routers, the value field must be contained 
in the IP Layer header. This is because the TCP Layer header 
is considered purely as data by the routers that implement IP 
protocols and, as such, it is to be transported without any 
reference to its contents. However, for the value field to be 
useful to individual client and server applications for the 
purpose of enumerating the intrinsic worth of the data being 
transported, it must be accessible to these applications. The 
applications operate at the Application Layer of the TCP/IP 
stack and this layer interfaces with the TCP Layer, with the 
IP Layer being effectively invisible to the application. The 
matter is further complicated by the existence of UDP (User 
Datagram Protocol), which provides an alternative protocol 
at the Transport Layer (and there might be additional alter- 
natives, which either currently exist or will be defined in the 
future). The invention proposes three solutions to this, as 
follows. 

[0067] The first solution is to have separate value fields. 
According to this solution there are two distinct value fields, 
one in the IP Layer, to accrue measurement of the economic 
worth of performing the data transport operation, and one in 
the Transport Layer, to enumerate the intrinsic worth of the 
data. Such a solution does not allow the unification of the 
methods covering the two contributions to the economic 
model, and so is not the preferred solution. 

[0068] The second solution is direct communication 
between the application and the IP Layer. Such communi- 
cation can be hazardous with respect to the structure and 
implementation of the TCP/IP protocol and is not generally 
considered to be a realistic solution. There is a useful 
exception in the case of an "information server", a system 
dedicated to serving information on behalf of a content 
provider and which is accessed by a client dedicated to the 
task of receiving that information. A server in such a system 
can run [customised] customized application software, in 
which the direct access to the IP Layer is available as 
required. The client works solely with the incoming infor- 
mation, so that the resources consumed (and measured in 
accordance with PTP) on behalf of the client application are 
indistinguishable from the total resources consumed by the 
client machine. This is the maximum level of detail that 
could be measured if the PTP values were accessed directly 
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from the IP Layer, since IP does not work with reference to 
specific ports or the individual applications which are 
notionally attached to them. 

[0069] The third, most [favoured] favored solution is 
integration with the Transport Layer. The PTP value field is 
incorporated in the IP Layer header. The Transport Layer 
protocol (TCP, UDP or other) is aware of the value field and 
can convey the information to and from the Application 
Layer as required, even though this information is not 
written in the Transport Layer header and thus not consid- 
ered to be conveyed at the Transport Layer level. The act of 
reading and writing the value field would still be expected to 
be the preserve [of the] of the IP Layer implementation 
software. This structuring appears to be analogous to the 
way in which applications can have access to IP addresses, 
although these are actually written in to, and read back from, 
the IP headers. 

[0070] Practical details in implementing the router func- 
tionality required by the PTP system will now be described. 
Incrementing the value field does not impose an unaccept- 
able processing overhead on the router. There is a precedent 
for this kind of processing in the way that the IP standard 
defines and [utilises] utilizes a time-to-live (TTL) value in 
the IP header. This is subject to a decrement each time a 
router hop occurs. This capability can be extended to include 
a simple addition to the value field at the same point in the 
processing. This operation is likely to be an integer addition 
or binary add function on a specific bit field in the packet 
header, a relatively straightforward procedure. At the same 
lime developments in hardware technology will go some 
way to compensating for the increased burden placed upon 
the network infrastructure by the implementation of PTP. 
Dedicated hardware may be used to support the value field 
modification. Since there is an intimate relationship between 
the physical network connections and the particular value of 
the increment to be applied, an appropriate piece of equip- 
ment can be placed "in line" on each physical network 
connection, to perform the task. Such a unit can respond to 
its own communications protocol (something akin to the 
way routers work with ICMP (Internet Control Message 
Protocol), ARP (Address Resolution Protocol) and RARP 
(Reverse Address Resolution Protocol)) to receive updates 
to the algorithm for the value to be added to passing packets 
and also to return accumulated totals at appropriate times. 
Otherwise it operates as a standalone piece of network 
infrastructure, logging and incrementing the values of pass- 
ing packets. Such a configuration alleviates the need for 
routers to allocate the accumulating values to particular 
network connections or IP addresses in real time, as they 
process the packets. 

[0071] In addition, it is also possible that, rather than each 
and every router performing its own increment to the value 
field, a more "coarse grained" implementation of the PTP 
model could be applied. This would occur if the provider of 
a particular piece of infrastructure were willing to consider 
that piece of infrastructure (e.g., an optical [fibre] fiber 
"backbone") as a zone and therefore apply a more straight- 
forward tariff for transportation across the zone. This would 
mean that the logging and increasing of the value fields of 
packets transported across the zone would only need to take 
place at the zone boundaries. This scheme is effectively 
equivalent to considering the flow chart of FIG. 3 to apply 
to a network zone rather than an individual router. 



[0072] These and other modifications and improvements 
can be incorporated without departing from the scope of the 
invention. 

1. A method of electronic payment for data transferred 
across a computer network containing at least one client, at . 
least one server and at least one router which forwards data, 
the method comprising the steps of: 

sending an electronic data request from a client to a server 
via one or more routers; and 

sending electronic data from said server to said client yia 
one or more routers in response to said electronic data 
request, said electronic data having associated with it a 
data field containing a value which represents [the] a 
commercial value of [the data contained within] the 
electronic data. 

2. [A] The method according to claim [1]1 in which the 
electronic data is transmitted in the form of packets. 

3. [A] The method according to claim 2, wherein each of 
said one or more routers receives an incoming data packet, 
[reads the value in the] containing electronic data and a data 
field associated with the electronic data in the incoming data 
packet, reads the value in the data field, calculates a new 
value based on the read value and the cost of forwarding the 
data packet, and forwards the data packet with the new value 
in the associated data field. 

4. [A] The method according to claim 3, wherein each of 
said one or more routers checks whether the value in the data 
field associated with the electronic data in the incoming data 
packet falls within predefined parameters and rejects the 
packet if the value falls outside the predefined parameters. 

5. [A] The method according to [any preceding claim,] 
claim 1 wherein the electronic data request has associated 
with it a data field containing a [value] value which repre- 
sents the commercial value of the data contained within the 
electronic data request. 

6. [A] The method according to [any preceding claim,] 
claim 1, wherein total accumulated values for transactions 
between routers or between routers and servers/clients are 
recorded. 

7. [A] The method according to claim 6, wherein clear- 
ance payments are made between the operators and/or users 
of the routers and servers/clients, the clearance payments 
corresponding to the total accumulated values. 

8. A system of electronic payment for data based on a 
hardware infrastructure of linked routers, data providers and 
data users, comprising: 

at least one client; 

at least one server for providing electronic data in the 
form of data packets in response lo a request from a 
client and having [its] the at least one server's operation 
governed by a server protocol which causes each data 
packet sent by the server to have associated with it a 
data field representing the value of the data contained 
within the packet; 

at least one router linked by a hardware infrastructure to 
said server and said client and having its operation 
governed by a routing table and a router protocol; and 

whereby the router protocol causes each router to add 
commercial value to the packet by forwarding it in 
accordance with the routing table and to update the 
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value contained in the data field within the packet to 
reflect this added commercial value. 

9. [A] The system according to claim 8, wherein the router 
protocol also includes procedures for rejecting individual 
packets in accordance with pre-defined parameters related to 
the value of each packet on receipt. 

10. A method of electronic payment for data transferred 
across a computer network containing at least one client, at 
least one server and at least one part of the [network] 
network, which forwards data, the method comprising the 
steps of: 

sending an electronic data request from a client to a server 
via the part of the network; and 

sending electronic data from said server to said client via 
the part of the network in response to said electronic 
data request, said electronic data having associated 
with it a data field containing a value which represents 
the commercial value of the data contained within the 
electronic data. 

11. [A] The method according to claim [10]10, in which 
the electronic data is transmitted in the form of packets. 

12. [A] The method according to claim 11, wherein the 
part of the network has an associated data processor which 
reads the value in the data field associated with an incoming 
data packet received by the part of the network, calculates a 
new value based on the read value and the cost of forwarding 
the data packet, and forwards the data packel with the new 
value in the associated data field. 



13. [A] The method according to claim 12, wherein the 
data processor checks whether the value in the data field 
associated with the incoming data packet falls within pre- 
defined parameters and rejects the packet if the value falls 
outside the predefined parameters. 

14. A method of electronic payment for requested data 
transferred across a computer network containing at least 
one client, at least one server and at least one router which 
forwards data, in which the requested data is sent from said 
server to said client in the form of a packet, 

wherein said packet comprises a packet header and packet 
data, 

the packet data containing the requested data, and 

the packet header containing one or more address fields 
containing address information relating to the client 
and/or server and a data field containing a value which 
represents the commercial value of the requested data 
contained within the packet data. 

15. [A] The method according to claim 14, wherein the 
data is sent via the router which reads the value in the data 
field of the incoming data packet received by the router, 
calculates a new value based on the read value and the cost 
of forwarding the data packet, writes the new value to the 
data field, and forwards the data packet with the new value 
in the data field. 

***** 



